The following outlines OpenFlow, as one example of SDNs (Software Designed Networks) that can dynamically set or change a configuration, function, or performance of a network based on a software. OpenFlow switch includes a flow table including one or more flow entries. Each flow entry includes a match field to be matched with header field information of a received packet, a counter field including statistics information such as the number of received packets and the number of received bytes, and an action field with zero or more actions that dictate how the switch handles a received packet whose header field information matches the match field. Upon reception of a packet, the OpenFlow switch retrieves the flow table thereof using header field information of the packet. In the case of miss-hit (non-match), the OpenFlow switch forwards the packet to OpenFlow controller over a secure channel.
Based upon information on a source and a destination of the packet specified in the header thereof, the OpenFlow controller computes a path for the packet from network topology information. Based upon the path, the OpenFlow controller generates and sets a flow entry for each of OpenFlow switches on the path. On reception of following packets, each having a header matching a match field of the flow entry set by the OpenFlow controller, each of the OpenFlow switches on the path forwards the packets to a next node, for example, as prescribed in the action field of the flow entry. Regarding details of OpenFlow, reference may be made to NPL (Non patent Literature) 4 listed in the below.
There have been extensive research and development efforts on secure networking, especially in SDN (Software Designed Network) to reduce network vulnerabilities to attacks.
In NPL 1 listed in the below, there is proposed ROSEMARY controller, which implements a network application containment and resilience strategy based around the notion of spawning applications independently within micro-NOS (network operating system).
In NPL 2 listed in the below, there is proposed PermOF coping with potential trust issue on OpenFlow applications, in which abuse of trust could lead to various types of attacks impacting an entire network. In PermOF, isolation of control flow and data is established between a controller and applications. OpenFlow applications are isolated from Controller kernel, that is, OpenFlow applications cannot call kernel procedures or directly refer to a kernel memory. There is provided Access control layer between OpenFlow applications and OS (Operating System). The layer is controlled by the Controller kernel, so that undesirable interaction between OpenFlow applications and OS would be cut off.
In NPL 3 listed in the below, there is proposed AVANT-GUARD, a new framework to advance security and resilience of OpenFlow networks with greater involvement from the data-plane layer. Connection migration enables data plane to shield control plane from saturation attacks. Actuating triggers automatically insert flow rules when the network is under attack.